브라우저 확장 프로그램 백그라운드 스크립트: 자바스크립트 서비스 워커로의 전환 수용하기

브라우저 확장 프로그램 개발 환경은 끊임없이 진화하고 있습니다. 최근 가장 중요한 변화 중 하나는 백그라운드 스크립트가 기존의 영구적인 백그라운드 페이지에서 자바스크립트 서비스 워커로 전환된 것입니다. 크롬 기반 브라우저의 매니페스트 V3(MV3)가 주도하는 이 마이그레이션은 수많은 이점을 가져다주지만, 개발자들에게는 독특한 과제를 제시하기도 합니다. 이 종합 가이드에서는 이러한 변화의 이유, 장단점, 그리고 확장 프로그램의 원활한 전환을 보장하기 위한 상세한 마이그레이션 과정을 자세히 살펴보겠습니다.

서비스 워커로 마이그레이션해야 하는 이유

이 전환의 주된 동기는 브라우저 성능과 보안을 개선하는 것입니다. 매니페스트 V2(MV2)에서 흔히 사용되던 영구 백그라운드 페이지는 유휴 상태일 때도 상당한 리소스를 소비하여 배터리 수명과 전반적인 브라우저 응답성에 영향을 줄 수 있습니다. 반면에 서비스 워커는 이벤트 기반으로 작동하며 필요할 때만 활성화됩니다.

서비스 워커의 장점:

• 성능 향상: 서비스 워커는 API 호출이나 확장 프로그램의 다른 부분에서 온 메시지와 같은 이벤트가 발생할 때만 활성화됩니다. 이러한 "이벤트 기반" 특성은 리소스 소비를 줄이고 브라우저 성능을 향상시킵니다.
• 보안 강화: 서비스 워커는 더 제한된 환경에서 작동하므로 공격 표면을 줄이고 확장 프로그램의 전반적인 보안을 향상시킵니다.
• 미래 대비: 대부분의 주요 브라우저는 확장 프로그램의 백그라운드 처리를 위한 표준으로 서비스 워커를 채택하고 있습니다. 지금 마이그레이션하면 확장 프로그램이 호환성을 유지하고 향후 지원 중단 문제를 피할 수 있습니다.
• 논블로킹(Non-Blocking) 작업: 서비스 워커는 메인 스레드를 차단하지 않고 백그라운드에서 작업을 수행하도록 설계되어 더 원활한 사용자 경험을 보장합니다.

단점 및 과제:

• 학습 곡선: 서비스 워커는 영구 백그라운드 페이지에 익숙한 개발자들에게는 어려울 수 있는 새로운 프로그래밍 모델을 도입합니다. 이벤트 기반 특성은 상태 및 통신 관리에 다른 접근 방식을 요구합니다.
• 영구 상태 관리: 서비스 워커가 활성화되는 동안 영구적인 상태를 유지하려면 신중한 고려가 필요합니다. Storage API나 IndexedDB와 같은 기술이 중요해집니다.
• 디버깅 복잡성: 서비스 워커는 간헐적으로 작동하기 때문에 기존 백그라운드 페이지보다 디버깅이 더 복잡할 수 있습니다.
• DOM 접근 제한: 서비스 워커는 DOM에 직접 접근할 수 없습니다. 웹 페이지와 상호 작용하려면 콘텐츠 스크립트와 통신해야 합니다.

핵심 개념 이해하기

마이그레이션 과정에 뛰어들기 전에 서비스 워커의 기본 개념을 파악하는 것이 중요합니다.

생명주기 관리

서비스 워커는 다음과 같은 단계로 구성된 뚜렷한 생명주기를 가집니다:

• 설치(Installation): 확장 프로그램이 처음 로드되거나 업데이트될 때 서비스 워커가 설치됩니다. 이때 정적 자산을 캐시하고 초기 설정 작업을 수행하는 것이 이상적입니다.
• 활성화(Activation): 설치 후 서비스 워커가 활성화됩니다. 이 시점부터 이벤트를 처리할 수 있습니다.
• 유휴(Idle): 서비스 워커는 이벤트를 기다리며 유휴 상태를 유지합니다.
• 종료(Termination): 서비스 워커가 더 이상 필요하지 않을 때 종료됩니다.

이벤트 기반 아키텍처

서비스 워커는 이벤트 기반으로 작동하며, 특정 이벤트에 대한 응답으로만 코드를 실행합니다. 일반적인 이벤트는 다음과 같습니다:

• install: 서비스 워커가 설치될 때 발생합니다.
• activate: 서비스 워커가 활성화될 때 발생합니다.
• fetch: 브라우저가 네트워크 요청을 할 때 발생합니다.
• message: 서비스 워커가 확장 프로그램의 다른 부분으로부터 메시지를 수신할 때 발생합니다.

프로세스 간 통신

서비스 워커는 콘텐츠 스크립트나 팝업 스크립트와 같은 확장 프로그램의 다른 부분과 통신할 방법이 필요합니다. 이는 일반적으로 chrome.runtime.sendMessage 및 chrome.runtime.onMessage API를 사용하여 이루어집니다.

단계별 마이그레이션 가이드

일반적인 브라우저 확장 프로그램을 영구 백그라운드 페이지에서 서비스 워커로 마이그레이션하는 과정을 살펴보겠습니다.

1단계: 매니페스트 파일(manifest.json) 업데이트

첫 번째 단계는 서비스 워커로의 변경을 반영하도록 manifest.json 파일을 업데이트하는 것입니다. 기존의 "background" 필드를 제거하고 "service_worker" 속성을 포함하는 새로운 "background" 필드로 교체합니다.

매니페스트 V2 예시 (영구 백그라운드 페이지):

{
  "manifest_version": 2,
  "name": "My Extension",
  "version": "1.0",
  "background": {
    "scripts": ["background.js"],
    "persistent": true
  },
  "permissions": [
    "storage",
    "activeTab"
  ]
}

매니페스트 V3 예시 (서비스 워커):

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0",
  "background": {
    "service_worker": "background.js"
  },
  "permissions": [
    "storage",
    "activeTab"
  ]
}

중요 고려사항:

• manifest_version이 3으로 설정되었는지 확인하세요.
• "service_worker" 속성은 서비스 워커 스크립트의 경로를 지정합니다.

2단계: 백그라운드 스크립트(background.js) 리팩토링

이것이 마이그레이션 과정에서 가장 중요한 단계입니다. 서비스 워커의 이벤트 기반 특성에 맞게 백그라운드 스크립트를 리팩토링해야 합니다.

1. 영구 상태 변수 제거

MV2 백그라운드 페이지에서는 전역 변수를 사용하여 여러 이벤트에 걸쳐 상태를 유지할 수 있었습니다. 그러나 서비스 워커는 유휴 상태일 때 종료되므로 전역 변수는 영구 상태를 유지하는 데 신뢰할 수 없습니다.

예시 (MV2):

var counter = 0;

chrome.browserAction.onClicked.addListener(function(tab) {
  counter++;
  console.log("Counter: " + counter);
});

해결책: Storage API 또는 IndexedDB 사용

Storage API(chrome.storage.local 또는 chrome.storage.sync)를 사용하면 데이터를 영구적으로 저장하고 검색할 수 있습니다. 더 복잡한 데이터 구조에는 IndexedDB가 또 다른 옵션입니다.

예시 (MV3, Storage API 사용):

chrome.browserAction.onClicked.addListener(function(tab) {
  chrome.storage.local.get(['counter'], function(result) {
    var counter = result.counter || 0;
    counter++;
    chrome.storage.local.set({counter: counter}, function() {
      console.log("Counter: " + counter);
    });
  });
});

예시 (MV3, IndexedDB 사용):

// IndexedDB 데이터베이스를 여는 함수
function openDatabase() {
  return new Promise((resolve, reject) => {
    const request = indexedDB.open('myDatabase', 1);

    request.onerror = (event) => {
      reject('데이터베이스 열기 오류');
    };

    request.onsuccess = (event) => {
      resolve(event.target.result);
    };

    request.onupgradeneeded = (event) => {
      const db = event.target.result;
      db.createObjectStore('myObjectStore', { keyPath: 'id' });
    };
  });
}

// IndexedDB에서 데이터를 가져오는 함수
function getData(db, id) {
  return new Promise((resolve, reject) => {
    const transaction = db.transaction(['myObjectStore'], 'readonly');
    const objectStore = transaction.objectStore('myObjectStore');
    const request = objectStore.get(id);

    request.onerror = (event) => {
      reject('데이터 가져오기 오류');
    };

    request.onsuccess = (event) => {
      resolve(request.result);
    };
  });
}

// IndexedDB에 데이터를 넣는 함수
function putData(db, data) {
  return new Promise((resolve, reject) => {
    const transaction = db.transaction(['myObjectStore'], 'readwrite');
    const objectStore = transaction.objectStore('myObjectStore');
    const request = objectStore.put(data);

    request.onerror = (event) => {
      reject('데이터 넣기 오류');
    };

    request.onsuccess = (event) => {
      resolve();
    };
  });
}

chrome.browserAction.onClicked.addListener(async (tab) => {
  try {
    const db = await openDatabase();
    let counterData = await getData(db, 'counter');
    let counter = counterData ? counterData.value : 0;

    counter++;

    await putData(db, { id: 'counter', value: counter });
    db.close();
    console.log("Counter: " + counter);

  } catch (error) {
    console.error("IndexedDB 오류: ", error);
  }
});

2. 이벤트 리스너를 메시지 전달로 대체

백그라운드 스크립트가 콘텐츠 스크립트나 확장 프로그램의 다른 부분과 통신하는 경우, 메시지 전달을 사용해야 합니다.

예시 (백그라운드 스크립트에서 콘텐츠 스크립트로 메시지 보내기):

chrome.runtime.onMessage.addListener(
  function(request, sender, sendResponse) {
    if (request.message === "get_data") {
      // 데이터를 검색하기 위해 무언가 수행
      let data = "Example Data";
      sendResponse({data: data});
    }
  }
);

예시 (콘텐츠 스크립트에서 백그라운드 스크립트로 메시지 보내기):

chrome.runtime.sendMessage({message: "get_data"}, function(response) {
  console.log("수신된 데이터: " + response.data);
});

3. `install` 이벤트에서 초기화 작업 처리

install 이벤트는 서비스 워커가 처음 설치되거나 업데이트될 때 발생합니다. 데이터베이스 생성이나 정적 자산 캐싱과 같은 초기화 작업을 수행하기에 완벽한 시점입니다.

예시:

chrome.runtime.onInstalled.addListener(function() {
  console.log("서비스 워커가 설치되었습니다.");
  // 여기서 초기화 작업을 수행합니다
  chrome.storage.local.set({initialized: true});
});

4. 오프스크린 문서 고려

매니페스트 V3는 오디오 재생이나 클립보드 상호 작용과 같이 이전에는 백그라운드 페이지에서 DOM 접근이 필요했던 작업을 처리하기 위해 오프스크린 문서를 도입했습니다. 이 문서는 별도의 컨텍스트에서 실행되지만 서비스 워커를 대신하여 DOM과 상호 작용할 수 있습니다.

확장 프로그램이 DOM을 광범위하게 조작해야 하거나 메시지 전달 및 콘텐츠 스크립트로 쉽게 달성할 수 없는 작업을 수행해야 하는 경우 오프스크린 문서가 올바른 해결책이 될 수 있습니다.

예시 (오프스크린 문서 생성):

// 백그라운드 스크립트에서:
async function createOffscreen() {
  if (await chrome.offscreen.hasDocument({
    reasons: [chrome.offscreen.Reason.WORKER],
    justification: '문서가 필요한 이유'
  })) {
    return;
  }
  await chrome.offscreen.createDocument({
    url: 'offscreen.html',
    reasons: [chrome.offscreen.Reason.WORKER],
    justification: '문서가 필요한 이유'
  });
}

chrome.runtime.onStartup.addListener(createOffscreen);
chrome.runtime.onInstalled.addListener(createOffscreen);

예시 (offscreen.html):

<!DOCTYPE html>
<html>
<head>
  <title>Offscreen Document</title>
</head>
<body>
  <script src="offscreen.js"></script>
</body>
</html>

예시 (offscreen.js, 오프스크린 문서에서 실행됨):

// 서비스 워커로부터의 메시지 수신 대기
chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
  if (request.action === 'doSomething') {
    // 여기서 DOM으로 무언가를 수행
    document.body.textContent = '작업이 수행되었습니다!';
    sendResponse({ result: 'success' });
  }
});

3단계: 확장 프로그램 철저히 테스트하기

백그라운드 스크립트를 리팩토링한 후에는 새로운 서비스 워커 환경에서 확장 프로그램이 올바르게 작동하는지 철저히 테스트하는 것이 중요합니다. 다음 영역에 특히 주의를 기울이세요:

• 상태 관리: 영구 상태가 Storage API 또는 IndexedDB를 사용하여 올바르게 저장되고 검색되는지 확인합니다.
• 메시지 전달: 백그라운드 스크립트, 콘텐츠 스크립트, 팝업 스크립트 간에 메시지가 올바르게 전송되고 수신되는지 확인합니다.
• 이벤트 처리: 모든 이벤트 리스너가 예상대로 트리거되는지 테스트합니다.
• 성능: 확장 프로그램의 성능을 모니터링하여 과도한 리소스를 소비하지 않는지 확인합니다.

4단계: 서비스 워커 디버깅하기

서비스 워커는 간헐적으로 작동하기 때문에 디버깅이 어려울 수 있습니다. 서비스 워커를 디버깅하는 데 도움이 되는 몇 가지 팁은 다음과 같습니다:

• Chrome DevTools: Chrome DevTools를 사용하여 서비스 워커를 검사하고, 콘솔 로그를 보고, 중단점을 설정합니다. 서비스 워커는 "Application" 탭 아래에서 찾을 수 있습니다.
• 영구 콘솔 로그: console.log 문을 자유롭게 사용하여 서비스 워커의 실행 흐름을 추적합니다.
• 중단점: 서비스 워커 코드에 중단점을 설정하여 실행을 일시 중지하고 변수를 검사합니다.
• 서비스 워커 검사기: Chrome DevTools의 서비스 워커 검사기를 사용하여 서비스 워커의 상태, 이벤트 및 네트워크 요청을 봅니다.

서비스 워커 마이그레이션 모범 사례

브라우저 확장 프로그램을 서비스 워커로 마이그레이션할 때 따라야 할 몇 가지 모범 사례는 다음과 같습니다:

• 일찍 시작하기: 서비스 워커로 마이그레이션하는 것을 마지막 순간까지 미루지 마세요. 가능한 한 빨리 마이그레이션 프로세스를 시작하여 코드를 리팩토링하고 확장 프로그램을 테스트할 충분한 시간을 확보하세요.
• 작업 분할하기: 마이그레이션 프로세스를 더 작고 관리하기 쉬운 작업으로 나누세요. 이렇게 하면 프로세스가 덜 부담스럽고 추적하기 쉬워집니다.
• 자주 테스트하기: 마이그레이션 과정 전반에 걸쳐 확장 프로그램을 자주 테스트하여 오류를 조기에 발견하세요.
• 영구 상태에는 Storage API 또는 IndexedDB 사용하기: 영구 상태에 전역 변수를 사용하지 마세요. 대신 Storage API나 IndexedDB를 사용하세요.
• 통신에는 메시지 전달 사용하기: 백그라운드 스크립트, 콘텐츠 스크립트, 팝업 스크립트 간의 통신에는 메시지 전달을 사용하세요.
• 코드 최적화하기: 리소스 소비를 최소화하기 위해 성능을 위해 코드를 최적화하세요.
• 오프스크린 문서 고려하기: DOM을 광범위하게 조작해야 하는 경우 오프스크린 문서 사용을 고려하세요.

국제화 고려사항

전 세계 사용자를 대상으로 브라우저 확장 프로그램을 개발할 때는 국제화(i18n)와 현지화(l10n)를 고려하는 것이 중요합니다. 확장 프로그램을 전 세계 사용자가 접근할 수 있도록 하는 몇 가지 팁은 다음과 같습니다:

• `_locales` 폴더 사용: 확장 프로그램의 번역된 문자열을 _locales 폴더에 저장합니다. 이 폴더에는 지원되는 각 언어에 대한 하위 폴더가 있으며, 번역이 포함된 messages.json 파일이 있습니다.
• `__MSG_messageName__` 구문 사용: 코드와 매니페스트 파일에서 번역된 문자열을 참조할 때 __MSG_messageName__ 구문을 사용합니다.
• 오른쪽에서 왼쪽으로 쓰는(RTL) 언어 지원: 확장 프로그램의 레이아웃과 스타일이 아랍어 및 히브리어와 같은 RTL 언어에 올바르게 적용되는지 확인합니다.
• 날짜 및 시간 형식 고려: 각 로케일에 적합한 날짜 및 시간 형식을 사용합니다.
• 문화적으로 관련된 콘텐츠 제공: 확장 프로그램의 콘텐츠를 다른 지역에 문화적으로 관련되도록 맞춤화합니다.

예시 (_locales/en/messages.json):

{
  "extensionName": {
    "message": "내 확장 프로그램",
    "description": "확장 프로그램의 이름"
  },
  "buttonText": {
    "message": "클릭하세요",
    "description": "버튼에 표시될 텍스트"
  }
}

예시 (코드에서 번역된 문자열 참조하기):

document.getElementById('myButton').textContent = chrome.i18n.getMessage("buttonText");

결론

브라우저 확장 프로그램의 백그라운드 스크립트를 자바스크립트 서비스 워커로 마이그레이션하는 것은 성능, 보안을 개선하고 확장 프로그램의 미래를 대비하는 중요한 단계입니다. 전환 과정에서 몇 가지 어려움이 있을 수 있지만, 그 노력의 가치는 충분합니다. 이 가이드에 설명된 단계를 따르고 모범 사례를 채택함으로써 원활하고 성공적인 마이그레이션을 보장하고 전 세계 사용자에게 더 나은 경험을 제공할 수 있습니다. 서비스 워커의 힘을 최대한 활용하기 위해 철저히 테스트하고 새로운 이벤트 기반 아키텍처에 적응하는 것을 잊지 마세요.

추가 자료

• 크롬 확장 프로그램 매니페스트 V3 문서
• 모질라 서비스 워커 API 문서
• 서비스 워커 기본 사항